[RFC][utest] Add audio driver test framework #10243
Conversation
| int fd = -1; | ||
| int res = 0; | ||
| uint8_t *buffer = NULL; | ||
| void* player_buffer = NULL;struct rt_audio_caps caps = {0}; |
1078249029
force-pushed
the
audio_test
branch
2 times, most recently
from
e83b1b6 to
2655d6a
Compare
Achieve driver framework by operating memory to simulate audio peripheral drivers. And it could be as a draft standrad for other drivers test framework. Signed-off-by: 1078249029 <[email protected]>
|
@1078249029 这个PR准备好了吗？ |
准备好了，麻烦您review下。 |
|
@unicornx 老师，上次跟您说的音频测试框架已经写好了，您有空的话也请review？ |
📌 Code Review Assignment📊 Current Review Status (Last Updated: 2025-05-12 02:45 UTC)📝 Review Instructions
|
There was a problem hiding this comment.
我记得上次开会满老师 @mysterywolf 说建议后面 ut cases 都移到各个模块自己的目录下去，不要放到 examples 下了，本身这个 examples 就很让人迷惑。可以参考 src/klibc/utest 这个是满老师最新作的 utest 例子，貌似就是每个模块下自己维护一个 utest 目录然后在里面加测试代码。然后就是模仿 src/klibc/utest 下的代码写，包括 SConscript 里要 denpend RT_UTEST_USING_ALL_CASES ，还有配置选项名字统一加 'RT_UTEST_TC_USING_' 前缀，参考 'RT_UTEST_TC_USING_KLIBC'。
还有一个问题就是建议在测试代码中以注释的方式写一下测试的设计思想，直接 review 代码一下子不知道你的设计思路理解起来很费劲。这个测试代码需要依赖硬件吗？看注释有模拟的部分，可以说明一下。另外我理解这里测试的对象是 driver audio 的 API，所以 drv_mic.c 和 drv_player.c 应该是测试的主体，对吧。可以在注释中列一下你覆盖的 API 吗？
代码上，所有全局变量和函数，如果不是 extern 的请全部 static。
拉取/合并请求描述：(PR description)
[
为什么提交这份PR (why to submit this PR)
Fixed #10046
你的解决方案是什么 (what is your solution)
Achieve driver framework by operating memory to simulate audio peripheral drivers. And it could be as a draft standrad for other drivers test framework.
请提供验证的bsp和config (provide the config and bsp)
]
当前拉取/合并请求的状态 Intent for your PR
必须选择一项 Choose one (Mandatory):
代码质量 Code Quality：
我在这个拉取/合并请求中已经考虑了 As part of this pull request, I've considered the following:
#if 0代码，不包含已经被注释了的代码 All redundant code is removed and cleaned up